Mac Mania 4/MacMania 4.toast//Multimedia & Desktop/gsu-shane the plane demo/Fly SAFE with Shane the Plane!

Text File | 1993-07-08 | 75KB | 1,516 lines

Fly SAFE with Shane the Plane!

(A Power User's manual for Power User's software)


Documenting: Shane the Plane (version 2.0.1) © 1993 by Greg Swann

7/8/93

Greg Swann
CompuServe: 70640,1574
USPS: P.O. Box 1724
      Andover, MA 01810



Table of Contents

0. Entirely UNFAIR warnings...

1. Introductory Chatter...

2. Commercial, legal and other pertinent notices...

3. Shane the Plane - the quick hop...

4. Transcontinental Shane the Plane...

5. Not for Flight Engineers only...

6. About Greg Swann...

7. Conclusion...

Appendix: Real World Shane the Plane by Kip Shaw




0. Entirely UNFAIR warnings...

Don't say you weren't warned: This software is DANGEROUS!

Repeating: THIS SOFTWARE IS DANGEROUS!!

Nothing is buggy. Everything works as documented. But: almost
everything we're doing here is _inherently_ dangerous. This is most
emphatically _NOT_ intended to be used by novices. This is Power
User's software intended to be used by Power Users. There is nothing
being done here that could not be done by other (much slower) means,
but many of the functions performed by Shane the Plane would require
special software and a deep knowledge of Macintosh topology. Shane
the Plane offers fast, convenient brute-force to people who _could_
do these jobs manually. If you could not, do yourself (and your
"guru") a favor and drop out now. It's no stain to save yourself
unnecessary pain (grin).

There will be little warnings all the way through this manual, but I
wanted to establish a Global Warning Trend (groan!) right at the
top: if you don't know what the hell I'm talking about in this
document (and I'm deliberately not making things too easy), take
that as your cue that this is not for you. I'm not trying to talk my
way out of your money, but I surely don't want your money for giving
you the means to irreparably damage your files (taking careful note
that it will be your own damn fault if your do!).

On the other hand: if you _are_ a Macintosh adept, hang in. This is
definitely a jet-powered file-attribute management utility. The
whole point is learning to Fly SAFE with Shane the Plane...



1. Introductory Chatter...

This is a further development on the gross concept of the original
Shane the Plane (version 1.0.x), a FreeWare program that can be
found on CompuServe and other electronic information services. The
original Shane the Plane optionally changed the creator and type of
files, and/or their created/modified dates and times. Shane the
Plane version 2.0.1, this software, continues to do that stuff, but
it also intelligently renames files, inserts the file's name as a
"slug" in text files, and permits really radical batch editing of
significant Finder flags (for example, you can "Paste" custom icons
into a huge batch of files very quickly).

The original FreeWare Shane the Plane is available and will always
be available for free. But: Shane the Plane 2.0.1 is commercial
software: you can't use it (for long) without paying me. The copy of
Shane the Plane in this archive is a DemoWare version that will
permit up to 32 launches and then forevermore refuse to do anything
but be an automated salesman. It is a _fully functional_ demo.
Nothing is crippled. The only inhibition is the one named: 32
launches, max. See "Commercial, legal and other pertinent notices"
below for information on how to purchase unrestricted copies of
Shane the Plane.


This software is named for Shane Stanley, de facto product manager
for all of my commercial programs and the quiet voice of reason
behind virtually everything I do. Shane has been unstinting in the
benefits he has conferred upon me, and I can never hope to repay
him. We've worked together for a little over a year, and in that
time my respect for him has grown geometrically. He's a very
valuable business associate (to the extent that you can call what I
do a business), but _much_ more important, he's a very highly valued
friend. I'm proud to have produced a piece of software that is
_almost_ worthy of its namesake.

Here's the story: when we were working on version 1.0.0 of Shane the
Plane, I was casting about for a name. I had already written two
pieces of software named after Shane, but neither was released - the
second because it was trivial and the first because it was a little
too user-friendly... But I wanted to name something (useful) in his
honor, and I'd been waiting for the right thing. It happens that I
was talking to my four-year-old daughter, Meredith, (in a very
general way) about this project, and I asked her what I should call
it. "Shane the Plane," she said, that being her name for all
airplanes. Shane's name comes up in conversation a lot, and she
worked out the rhyme on her own. And names for "things" are a big
deal right now; the computer I'm working on is named "Amber", after
Meredith's favorite kind of traffic light. Meri made the original
icon, a biplane painted brown to blend into the rugged outback of
Shane's native Australia. She also made the jet icon that graces
this version.

With some validity, this could be named after Kip Shaw, since it was
he who got me thinking about many of the problems it solves.
Notably, creator/type changing, intelligent file renaming, and text
file "slugging" are all responses to conversations with Kip about
things we'd like to be able to do. Renaming and slugging are pieces
of a software puzzle Kip is putting together to automate a
significant part of his publishing work. Another piece of that same
puzzle is the FreeWare program ShawBerry, named after Kip, which is
stored on CompuServe (as BERRY.CPT in Library 5 of the DTPForum) and
other electronic information services.


Shane and Kip were the beta testers for this version of Shane the
Plane, and, as always, they have my gratitude. Even more than
"always", perhaps, since they were testing a huge piece of software
that was largely in flux until the bitter end.


TechnoBabble: Shane the Plane is compatible with both Systems 7 and
6. It is AppleEvent-aware, so, presumably, you could script to it
from an intelligent agent. It's 32-bit clean, MultiFinder aware, a
real fun date - all the usual stuff. In short (there will be much
more later), it's everything you expect of up-to-the-microsecond
Macintosh software.


Notes on this text: this file is written as plain text in DOS-like
fashion (i.e., every line ending is a carriage return). It is
produced in a FreeWare Programmer's editor called BBEdit by Rich
Siegel (which is recommended). I've had mail about this, so I'll
explain: I produce documents this way because doing so makes no
presumptions about what software and fonts you might own. _Most_
word processors can open, e.g., MS-Word files. But _all_ word
processors can open _this_ file.



2. Commercial, legal and other pertinent notices...

As mentioned above, this is a DemoWare version of Shane the Plane,
fully functional but limited to 32 launches. The full unrestricted
commercial release can be obtained from Greg Swann at:

    P.O. Box 1724
    Andover, MA 01810

Licenses are sold per machine, with a single license costing $40;
2-10 licenses are $35 each; and 11 or more licenses are $30 each.
(Write me if you want to negotiate an unlimited site license.)

I've thoughtfully (grin) provided a TeachText order form with this
archive. (Take note that this order form requires a PICT-aware
version of TeachText; use the version that came with your System
software, or open the file through some other PICT-aware software
(such as PhotoShop or MacDraw).)

Why is this version DemoWare? As with everything in my life, there
is philosophy here: I don't like crippled software. I don't think
much of ShareWare. And I almost never buy "a pig in a poke". In
deciding on a marketing scheme, I looked for something that would
be most appealing to _me_, were I in your shoes. This is what I've
come up with: a fully functional demo that lets you _find out_ if
Shane the Plane is a useful tool in your working environment. If it
is (and obviously _I_ think it will be), then pay me. If it isn't,
then ditch it when it starts to offer to make coupons for you as a
full-time gig. A good deal all around, I think: no guilt for you,
no guilting for me; maybe useful software for you, maybe useful
money for me (grin).

(For those who must have it both ways: it would certainly be
possible to download this archive again and again, just to get
access to more launches. Even cleaner, a determined thief could
keep a pristine copy and spawn duplicates to use until they're
exhausted. My take on this is simple: so be it. I work _very_ hard
on the things I make, and I don't want to think that my labor is
going to support people who are overtly hostile to the life of the
mind. But I certainly don't want to be _compensated_ for that
unintended outcome. I may not get my due _from you_, but nature is
just: in the long run, I'll get what's coming to me - and so will
you.)

(And if this is the first time you've read a software manual by me:
you'll get used to it... (grin))

Shane the Plane, its source and executable code, and this poor
excuse for a manual are Copyright (C) 1993 by Greg Swann. All
rights are most emphatically reserved.

The unrestricted (non-DemoWare) version of Shane the Plane is
licensed for use on one machine by the person who paid for it. If
you didn't pay for it, please do! I am one person, with a
long-suffering family, not Conglomerated MegaSoft (not to imply
that there's any virtue in ripping _them_ off!).

Shane the Plane is delivered "as is", without any warranties,
expressed or implied. It is not warranted to be useful _to_ anyone,
_for_ anything, and in no wise am I to be held responsible for any
unfortunate consequences resulting from its use or misuse. And I
_hate_ having to say things like that. I do my best to write
useful, simple, elegant, bug-free solutions to difficult problems.
If you take it into your head that I represent your big chance to
"strike it rich", you will pay a lot in legal fees to discover that
you have miscalculated.

And: to those to whom the above disclaimers do not apply: forgive
me for having to make them. It's _you_ whom I'm working for, for
pay or for free. I appreciate your patronage and your support, and
I wish we all could just comb the others out of our hair...

(Hey, it's a real 'personal' software company! (grin))



3. Shane the Plane - the quick hop...

This is an accelerated introduction to Shane the Plane's features
and functions. Frankly, I think you should read the detailed
instructions below. But if you're simply in _too_ big a hurry, this
will get you airborne with Shane the Plane.

Here's what you do: Drag & Drop _copies_  of some files on the icon
or an alias of it. Set some switches. Hit Start. If the results
aren't all you dreamed, try again. Hammer away all afternoon, if
necessary. This is the _Mac_, dammit, and we are constitutionally
exempted from reading manuals, even when doing so would be _far_
faster than "intuiting"... (wry grin)

Seriously: if you reason well, you can puzzle this out on your own.
But: if you reason well, perhaps a word to the wise will be
sufficient: This software is DANGEROUS!

In other words, _please_ take the time to find out what all these
controls and switches do. Noodle around with copies of files until
you're comfortable with the jobs you'll be doing. Back off and
re-read as soon as something you hadn't expected happens. Commit
yourself to this software _only_ when you've committed its behavior
to memory. By being modal (to the point of user-hostility in
places) we're insulating you from the worst consequences. But the
next-to-worst are very far from good, and I'd hate for anyone to
"quick-start" their way into a slow restoration...

...now do as you will.



4. Transcontinental Shane the Plane...

(If you use other software by me, there are a couple of big
differences in Shane the Plane from my normal methods. First,
because it seemed likely to me that few Shane the Plane jobs would
use the previously established preferences, you _must_ hit the
Start button for execution to begin on a Drag & Drop batch of
files. In other words, my expectation is that nearly every job will
require some switch-setting, so the default behavior is to make you
explicitly assert your readiness to begin by hitting the Start
button. Second, all of the changes made by Shane the Plane are done
"in place"; no new files are created. Normally, my stuff copies
from the source file to a new (uniquely named) destination file,
leaving the source untouched. Since Shane the Plane exists to
modify pre-existing files, that is not done here. This is not
terribly important except for this: if something goes badly wrong,
your file(s) may be toasted. We are watching our own butt (and
yours), but there's no accounting for acts of nature, etc. In
truth, where we are doing dangerous things, we are doing them in
the same way they are done by software costing 10 times as much as
Shane the Plane. But: be careful anyway. If a file is
irreplaceable, then work on a copy, replacing the original only
when you're sure all is well. (This is good advice in general!))

Shane the Plane runs out of a single dialog box, plus the menu bar.
About and Quit are familiar to everyone. The Command key
equivalents for Copy, Paste, and Cut work. Restore defaults
restores all settings to their "factory" defaults. Restore saved
preferences restores the settings to those most recently saved. And
Save preferences saves the current settings as the future defaults
to use at launch time. In other words, if you have a set of
operations you do endemically, make those your saved preferences.
Then, when you have a job that doesn't fit the mold, make temporary
changes, execute the job, and quit without saving the preferences.

There is a special logic to the way Shane the Plane handles files
delivered by Drag & Drop (available with System 7 only). Works like
this:

1. If Shane the Plane is launched by means of Drag & Drop, the
settings you establish are applied to that batch of files when you
hit the Start button, and then Shane the Plane quits without having
to be told to quit.

2. If you launch by double-clicking on the icon (or an alias of
it), then Shane the Plane must be quit explicitly (that is, you
must select Quit from the File menu or type Command-Q). If you hit
the Start button (without having Dragged & Dropped files), you will
be presented with a Standard File dialog box from which you can
select _one_ file, which will then be processed with the settings
you have established (this is the only way of using Shane the Plane
with System 6). On the other hand, if you double-click launch and
then Drag & Drop files, the settings you establish are applied to
that batch of files when you hit the Start button, but Shane the
Plane _does not_ Quit on its own at the end of the batch.

(There is one exception to this logic: when you have Dropped a
batch of files, a "Clear batch" button becomes visible. If you hit
that button, the batch of files will be cleared from memory, and
Shane the Plane will revert to the interactive state. In other
words, if you launch with a Drag & Drop batch, the software will
Quit automatically after processing if you hit Start, but will
_not_ Quit if you hit Clear batch.)

In this way you get the best of all worlds: quick, non-intrusive
Drag & Drop, fully interactive operation, or interactive Drag &
Drop.

(Important: when files are processed by Drag & Drop, we are giving
you a great deal of information about their native state (viz.,
creator and type, current Finder flags settings, file names, etc.).
We can't give you this news about files processed interactively
(the System 6 way), since we but barely know it before it's old
news. The _best_ reason to use Shane the Plane by Drag & Drop is
that it's _much_ faster. But this is _another_ reason: it's a much
more information-rich (hence safer) way to fly...)

(Also important: certain features of Shane the Plane take advantage
of Finder features available _only_ with System 7. These are: Lock
file name and the three check boxes relating to custom icons. These
check boxes will be disabled if you launch with System 6.)

In the dialog, there are five primary check boxes that govern the
behavior of the subsidiary controls indented beneath them. If the
primary check box is checked, the controls beneath are honored;
otherwise they're ignored. The "factory" settings for the primary
check boxes have them all unchecked. If you make any demonstrably
affirmative change to a subsidiary control, the appropriate primary
control will be checked automatically. The primary check boxes are
these:


Change creator/type: changes the creator and type of the file(s)
selected (surprise). The two text fields beneath the check box
allow you to establish which Creator and Type codes to use. These
default to 'R*ch' and 'TEXT' because that's what I need most often
(and whom should I please if not myself? (grin)). You can use
'****' as a wildcard meaning, "Stet. Leave this field the way it
is". If you Drag & Drop files, the Geneva text under the text
fields is the creator and type of the _first_ file in the batch.
Reasonably intelligent error-checking is going on in these fields
when you hit the Start button.


Change Finder flags: This is very complicated, so we're going to come
back to it after dispensing with the others.


Change date/time: The Change date/time check box controls whether or
not the created and modified dates of the file(s) will be altered.
If checked, both will be changed to the same date and time. The
format shown in Geneva beneath the text fields is a reflection of
your Control Panel date set-up. If you're set up for U.S.-style
dates, you'll see "MM/DD/YY", and you must enter dates that way. If
you're set up for non-U.S.-style dates, you'll see "DD/MM/YY", and
you'll enter dates that way. No matter what, the times must be
entered as "HH:MM:SS", using a 24-hour clock (i.e., the second
before midnight is 23:59:59, and the second after midnight is
00:00:01). Reasonably intelligent error-checking is going on in
these fields when you hit the Start button.

The date/time pop-up requires a bit of explanation because it does
two things. First, it establishes the form that the date and time
will take on the next launch (if you Save preferences). But it
_also_ gives you 10 plug-and-play options to use on the fly. Use
preferences uses the strings from the most recently saved
preferences, _not_ the result of the saved state of the pop-up
itself. Likewise for Use defaults. These are provided so that you
can store literal dates and times, as opposed to the
software-generated forms used by the others.

Clear as mud? Here's the deal: we're actually "storing" the dates
and times in two ways in the preferences. We're storing the current
switch setting of the pop-up, _and_ we're storing the actual text
of the editable fields. If you set the pop-up to Today at midnight,
but _then_ enter "01/02/93" in the date field, and then Save
preferences, when you launch again, things will be thus: the pop-up
and the date shown will reflect Today at midnight for every
midnight of every today for all eternity. But: if you select Use
preferences, you'll see "01/02/93". This will remain, steady as a
rock, until the next time you Save preferences. This was done this
way for a reason: suppose you want to modify work done over several
days so that it all has the same date applied to it. You could wait
and do the whole batch all at once. Or you could take advantage of
this feature to date-stamp it as you go along. This feature is so
well thought out that _no one_ understands it! (grin) Play with it
in connection with Save preferences, and you'll see what's going
on.

(And a brief word about date modification: it would be very easy to
use this feature for fraudulent purposes. You could claim to have
started something before you really did, swear up and down that you
didn't make a change that you _did_ make, divert accusing fingers
of blame toward unsuspecting innocents. This is one of the reasons
that Created and Modified are not independently editable: I can't
think of an honorable reason why anyone would need to do this. But,
even so, it's still possible to commit fraud with Shane the Plane,
and all I can say is this: I hope you don't. The finite time of
your life is your only asset, and I would hope you wouldn't choose
to squander it with ego-destructive acts...)

(And another brief word about date modification: certain disk
repair utilities (notably The Norton Utilities) don't like files
with odd dates. If you use this time machine to move files to the
distant past, or to any point in the future, prepare to face a
quizzical modal dialog from your disk fixer. No consequences, just
an opportunity to fix or ignore.)

(And a final word about date modification: what's it for? Sex
appeal, that's all. When you're delivering work that's twice-slick
in every other respect, it's thrice-slick to have every file set to
the same date and time. Software developers reading this will know
_exactly_ what I mean. Racing stripes don't make sports cars _run_
any faster; they just make them _sell_ faster (grin).)


Change file names: Here am I hoist by my own petard! As discussed
below in "About Greg Swann", I write a lot of file conversion
utilities. Each of these makes its own files from the source files,
adding its own "extension" to make a unique file name. What's
worse, many of these are eminently useful if used in combination.
In the long run, I'll be combining _many_ of these utilities in an
omnibus word processor that is as yet unnamed (but which we call
MyEditor to distinguish it from, for example, YourEditor (grin)).
But, for now: it's very easy to have a file called
"theFile.TQM.XP8.TQM.SB!". Many of the options in Change file names
exist to contain this mad proliferation of extensions.

In the pop-up menu, you have these choices:

Prompt individually - presents a dialog showing the current file
name and inviting you to change it manually.

Use text file’s slug line - intelligently parses the slug line
inserted by a prior pass through Shane the Plane (see "Insert slug
line in text files" below). If a Shane the Plane slug line is not
found, this renames the file with text from the file. The method of
selecting text is this: starting from the first non-white-space
character, assemble up to 31 characters of text or up to the next
return character found, omitting any trailing whitespace
characters. In all cases, colons are converted to hyphens (since
the colon is the path separator in the Mac OS), and control
characters are converted to space-bands.

(If the file is _not_ of type 'TEXT', the name will not be changed.
Depending on the state of the Auto-pilot|Prompt radio group, Shane
the Plane-inserted slug lines are either omitted or retained. If
the slug line was not inserted by Shane the Plane (viz., if we are
just using text from the top of the file), the slug is not omitted.
If Auto-pilot is selected, and if we find a Shane the
Plane-inserted slug line, then the slug line and any trailing white
space characters are removed. If Prompt is selected, you will be
prompted (once per session) as to whether you want to retain or
omit Shane the Plane-inserted slug lines. This was done so that, if
you are inserting slug lines for temporary reasons, you can get
them back out efficiently.)

Remove all extensions - removes all extensions, from last to first.
For all of these menu entries, an extension is defined as
non-white-space characters at the end of the file name, fingering
backward to a period character. The extension of "theFile.txt" is
".txt", but "theFile.txt Copy" _does not have an extension_, since
there is a white-space character between the end of the line and
the period. In all cases, we retain any text that does not fit this
definition. If you ask to have 3 extensions removed and only 2 are
found, only those 2 will be removed. We're being extra-careful
about this, because injudicious use of this function could result
in the loss of files.

Remove all but 1st ext. - would convert "theFile.TQM.XP8.TQM.SB!"
to "theFile.TQM".

Remove last ext. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM.XP8.TQM" or "theFile.TQM" to "theFile".

Remove last 2 exts. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM.XP8".

Remove last 3 exts. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM".

Custom extension - uses the text entered in the Extension text
field below the pop-up. Both Extension and Prefix are limited to
four characters, and a reasonable amount of error-checking is going
on when the Start button is hit.

(Why four characters? Since a Macintosh file name is limited to 31
characters in length, even four characters represents a significant
fraction of its total size. The longer an extension or prefix is,
the greater the likelihood of introducing duplicate file names.
Shane the Plane adds _only_ the number of characters actually typed
in the field. So, for example, the default Prefix ("• ") adds only
two characters. If you really want a much longer prefix or
extension (which I think is a Bad Idea (not, mind, a Real Bad
Idea)), load it into the paste buffer and use Prompt individually,
pasting it into each name. Alternatively, run twice with different
text in the affected field.)

Custom, removing exts. - same as above except that all pre-existing
extensions are removed before the new one is tacked on.

Prefix - works like Custom extension except that the Prefix is put
at the _front_ of the file name. This can be useful for forcing a
sort ordering in List by Name view in the Finder, etc.

Prefix, removing exts. - take the previous two and interpolate
(grin).

Remove prefix - removes a file name's prefix in a fairly tightly
defined sort of way. The problem is this: extensions are pretty
much an accepted standard, going back to Unix and before. We can
all agree what an extension looks like and respond accordingly. But
the concept of prefixing file names is new with the Mac, and there
really isn't any accepted practice about how to do it. So what
we're doing is this: first, we're examining the Prefix text field.
If the first N characters of the file name match the N characters
of the Prefix you've typed, we are omitting those N characters.
That means that _you_ can establish what you want removed by typing
into the Prefix text field. Second, if that test fails, we are
looking for a prefix in the form of: 1 non-white space character
immediately followed by 1 white space character (e.g., "* "). A
non-white space character is any legal file-naming character
_other_ than space or option-space. A white space character is
either space or option-space, nothing else. If the file name
matches that "mask", we remove the first two chararters (only) of
the file name.

Rename with wildcards - uses Torquemada's syntax to give you a batch
renaming capability such as the DOS- and UNIX-heads are always
boasting about. Rub their noses in this, because it's _much_ more
powerful. Unfortuantely, it's somewhat more complicated, first
because Mac filenames are larger and more flexible than what passes
for filenames under DOS, and second because Torquemada's complexity
can leave users somewhat at sea. This feature was requested by Mike
Arst and was added with version 2.0.1. It is extremely Arstian in
its form, so, if you don't feel perfectly comfortable with it, just
walk on by. Me feeling is that it has the potential to be immensely
time-saving once in a blue moon, which scores it as a win in my
book. If not in yours, it's cool. Really. (grin)

No business like UI business: if you select this in the pop-up,
when you hit the Start... button you will be prompted for a source
filename mask and a destination filname mask. These are analogous
to Torquemada search and replace strings, and, in fact, they are
entered in exactly the same way. If you're working interactively
and you pop-up out and back in, you will be prompted for new masks.
Otherwise, the masks will persist indefinitely (that is, until you
Quit). Obviously, when you D&D you're only going to see them once,
no matter what.

At the time the renaming business happens, the current filename
plus the two masks are delivered to code that is, in fact, culled
as is from Torquemada 1.2.2. In other words, in principle, every
TQM 1.2.2 S&R operation can be done to your filenames. In practice,
there are some limitations. If your filename ends up longer than 31
characters, something must be done. If Auto-pilot|Prompt is set to
Prompt, you will be prompted for intervention. If Auto-pilot is
set, the name will be truncated mercilessly at the 31st character.
Obviously, you're never going to get a colon (":") into a filename,
since that is the one illegal character in Mac filenames (another
big score on D(uh)OS). Certain Torquemada constructs are meaningless
(e.g., "^t" (tab) and "^p" (return)), since Shane the Plane
insulates _all_ control characters in filenames as spacebands. And,
finally, the Mac OS ignores without comment name-change requests
that entail _only_ changes in case. In other words, the
case-changing TQM commands _work_, but you have to change more than
the case to get the Mac OS to concede that a change should really
happen. _Any_ change is sufficient; a trailing space, a leading
bullet, a change in spelling - anything that makes the old and new
names different when case is ignored.

The manual that ships with Torquemada 1.2.2 runs to about 12,000
words, rather more space than I want to devote to one feature of
Shane the Plane. So for a fuller understanding of the commands
summarized below, refer to the Torquemanual. Incidentally (and
mercenarily), if you're using Torquemada 1.1.0 (the FreeWare
version), this list should make plain why you should upgrade: the
stuff that's new is way powerful.

RENAME WITH WILDCARDS QUICK REFERENCE

ALIASES—Match special text characters
  ^T or ^t    Tab
  ^P or ^p    Carriage return
  ^^          Caret
  ^˙          ˙  ({OPT-h})
  ^˚          ˚  ({OPT-k})

UNTYPED WILDCARDS—Match any one character
  ^0, ^1, ^2, ^3, ^4

TYPED WILDCARDS—Match any one character of that type
  ^+    Uppercase character (includes accented characters)
  ^-    Lowercase character (includes accented characters)
  ^±    Character of either case (includes accented characters)
  ^&    Alphanumeric character (letter or number, not space or punctuation)
  ^%    Tabular character (digit, space or punct.; not alphabetical)
  ^$    Printable character (all characters _except_ space characters)
  ^¢    Any character _EXCEPT_ return
  ^!    Punctuation character (includes high-ASCII punctuation)
  ^.    Sentence Punctuation character (.,;:!?)
  ^#    Numeric character (digits only)
  ^_    Space character (space, return, tab, option space)
  ^¬    Space character (space, tab, option space, but _NOT_ return)

DO-IT-YOURSELF WILDCARD-Match any one character of the type you define
  ^«...»    "..." is your definition

WILDSTRINGS—Match and store any text until full pattern is matched
  ^*, ^~, ^?, ^@

THE WILDSTRING MODIFIER-Constrain following wildstring to type of
                        preceding wildcard or character
  ^<

CASE CONVERSION COMMANDS—Can be used only on the replace side;
                         accented characters are handled
                         intelligently
  ^C or ^c    CONVERT TO ALL CAPS
  ^L or ^l    convert to all lower case
  ^S or ^s    Convert to sentence caps
  ^U or ^u    Convert To Upstyle Caps
  ^D or ^d    Convert to Downstyle Caps
  ^=          Cancel all case conversion

If you Drag & Drop files, the name of the _first_ file will appear
in Geneva below the Prefix and Extension fields before you hit
Start. After you hit Start, the names of the files in the batch
will be shown in sequence as they are processed.

The Auto-pilot|Prompt radio button group controls how Shane the
Plane deals with untoward file naming events. If the newly created
name is the same as that of a file that already exists in the
destination folder, that other file will either be replaced
automatically or you will be prompted for action, depending on the
state of this radio button. If adding a Prefix or Extension would
result in a file name longer than 31 characters (the Mac max), the
name will either be truncated automatically, or you will be
prompted for action. If it is truncated automatically, the
truncation will happen to the _base_ name, _before_ the addition of
the new text. In this way (with Extensions), you preserve the
characters you're trying to add! As discussed above, the
Auto-pilot|Prompt radio group determines whether you will be
prompted to discover if you want to omit Shane the Plane-inserted
slug lines when Use text file's slug line is selected, or if you
want them to be omitted automatically. Finally, if the new name is
exactly the same as the old name, the renaming will either be
skipped or you will be prompted for action, depending on the state
of this radio button. My advice: leave it set to Prompt (the
factory default). You won't be prompted that often, but Murphy's
Law of Disk Recovery Software says that the only file that can't be
recovered is the one that can't be replaced. The File You Save May
Be Your Own!

(About "Prompting": this is all run out of a smart dialog that
tells you what it wants you to do and won't let you do anything
illegal. It's oppressively modal, but there is nothing in Mac-land
that is quite so modal as naming files.)

(Modal: This is so much a part of the Mac landscape that we tend
not to notice it. The thing that makes character-oriented software
so loathsome to use is its overuse of "modes". You can't select
when you're in the insertion mode; you can't type when you're in
the selection mode. Mac software is modeless wherever possible,
introducing modes _only_ where modelessness would be inherently
dangerous. A Macintosh mode is denoted by a modal dialog box, and
you _must_ legally dismiss that dialog before you can proceed.
Thoughtful handling of modelessness and modes is what separates the
sheep from the lambs among Graphical User Interfaces. More than
anything else, this is what makes also-rans like Windows and Motif
seem so alien to Mac hacks.)


Insert slug line in text files: this inserts the current name of the
file in any file _of type TEXT_. All other types are ignored. This
option is disabled when "Use text file’s slug line" is selected in
the "Change file names" pop-up, for obvious reasons. Fair warning:
do not use this on Styled Text files! A Styled Text file (such as
those produced by Nisus) has the creator type 'TEXT', but there are
pointers into the text in the resource fork that will be hosed when
the slug line is inserted. Every one of those pointers will be
"off" by the number of characters in the slug line, which will
produce interesting but not very useful results. In the same
respect, certain text editors (such as BBEdit) store the current
insertion point/selection in the resource fork. These pointers will
also be "off" by the size of the slug line, but this is far smaller
consequence.

(Kip asked during testing what might be the consequences for RTF
files. My answer: I don't know. I don't use RTF, so I don't know
how fussy it is. If you _do_, test this function on a _copy_ of
your RTF file before committing to it as a useful procedure.)

The slug line looks like this (everything between but not including
the rows of dashes):

-----
// Filename: nameOfFile

-----

"// Filename: " is for uniqueness in searching (as with my own
Torquemada the Inquisitor) and because anything (on one line) after
two slashes is interpreted as a comment in Think C and all C++
compilers (viz., programmers can use Shane the Plane to comment
their source files with the name of the file). The extra return is
there to be pretty (grin). "nameOfFile", of course, is the current
(possibly newly changed) name of the file. The slug is prepended at
the zeroth position in the file, and everything after that is the
literal text from the file. The resource fork of the file is not
changed.


Change Finder flags: okay, now we're back to this. This is
complicated enough that we're doing as much as we can to simplify
it. For example, with Drag & Drop batches, we are collecting
information about the pre-existing state of files and reporting it
by means of graphic symbols (thus making one of the busiest dialogs
in Mac history, alas).

Two of these symbols are generic, and two are specific to a
particular check box.

The diamond symbol refers to the first file in the Drag & Drop
batch. It tells you that particular Finder attribute is _set_ in
the first file in the batch (this may not be true for _every_ file
in the batch). If you want to _retain_ this attribute (for the
whole batch), you must check the associated check box.

The circle symbol refers to _some_ (and possibly all) files in the
batch. It is used with "Remove custom icons" and "Remove PS font
BNDLs" to let you know that one or more files in the batch meets
the criteria for those check boxes. Since those functions are
harmless on files that _don't_ have the appropriate resources, it's
safe to run them on (what might be) a mixed batch.

The square symbol refers _only_ to "Make all in folder visible". It
tells you that one or more files in the folder(s) where files
reside are currently invisible.

The triangle symbol refers _only_ to "Install custom icons". It
tells you that there are "pasteable" icons in the clipboard.

(All of this will make more sense when we discuss these switches in
detail. But first:)

The Macintosh Finder works asynchronously. That is to say, it
defers some jobs that it judges to be less important until one of
the following things occurs: 1. it gets around to doing them, 2.
the hardware is idle enough that it feels confident to have enough
time to do house-keeping, or 3. an update is forced by some user-
or software-initiated event. Why is this important? First, because,
with respect to these switches and some others, we're pulling some
cute stunts to force updates. And, second, because the cute stunts
don't work for every case, most notably for "Stationery pad" and
"Lock file name". So: keep in mind that if you don't see an
immediate update consequent upon the changes you have made, you may
need to close then open the folder (thus forcing an update).

Now then, these are the switches:

Lock file: This is the same as checking the Lock file check box in
the Get Info window. A locked file can't have its name changed
(except from Shane the Plane), can't be deleted (unless you hold
down the option key while selecting Empty Trash), can't be Saved
under its own name, and can't have a custom icon pasted into it
(except from Shane the Plane). (A previously locked file will
generate the stupid Finder message when accessed by Shane the
Plane, but it's meaningless in this context.) A diamond means the
first file in the batch is locked.

Lock file name: a file with its name locked can't be renamed from
the Finder (it can be from Shane the Plane), and can't have
custom-icons pasted in (except from Shane the Plane). Lock file
name is a nice feature for managers and consultants who look after
novice users. And, ideally, all printer font files should have
their names locked, since a font ceases to work as soon as its name
is changed. Take note that Lock file name is updated slowly by the
Finder, and that the file name may _not_ be locked when the file is
on the desktop (Finder bug?). A diamond means the first file in the
batch has its name locked.

Stationery pad: makes any document into a "template". Most
Stationery-aware applications will open it into an untitled window.
Take note that Stationery pad is updated slowly by the Finder. A
diamond means that the first file in the batch is a stationery pad.

Make invisible: in a Drag & Drop batch of files, makes all of them
invisible when checked. Interactively, makes the particular file
visible or invisible, depending on how the check box is set. The
difference is: you can't Drag & Drop an invisible file (grin). In
consequence, there will never be a diamond.

Make all in folder visible: for every file in the folder (but not
subfolders), makes all invisible files visible. Files you may not
have known were invisible (such as custom folder icons) will show
up as well. A square means one or more files in the _folder_ are
invisible. (Because files can be Dragged & Dropped from multiple
folders (about which more below), this will make visible all files
in _all_ affected folders; worth keeping in mind if you're looking
for a surgical strike and not the Scorched Earth policy.)

Has custom icon: sets or clears the flag _only_, depending on the
state of the check box. This by itself is pretty useless; it's this
guy's two children who do the interesting stuff. But: a diamond
means that the first file in the batch has this flag set.

Install custom icons: if there are icons in the clipboard, they
will be pasted into all files selected, and the custom icons flag
will be set if this check box is checked. If there are no icons in
the clipboard, you will be invited to copy some in. This is
elemental coolness made flesh, in my not very humble opinion
(grin). Does nothing you couldn't do by hand from the Finder, but
Shane the Plane does it so much faster. Like much of Mac-cool, this
is nothing more than the sizzle on the steak; but what sizzle! A
triangle means there are icons in the clipboard at the time of the
Drag & Drop.

Remove custom icons: rips out all ICN#-family resources (with I.D.
-16455) found in the batch and clears the custom icons flag. A full
set of color icons takes up ±2.5K, so the disk space savings can
add up over a large batch (which you can then proceed to squander
with the above-mentioned switch? (grin)). A circle means that one
or more files in the batch have the custom icon flag set (implying
the presence of icon resources). Since only particular resource
types with the I.D. number -16455 are removed, this is harmless if
used on a file that _doesn't_ have any custom icons.

Has BNDL resource: sets or clears the bundle bit _only_ (again,
this is the dopey father to the wise child below). Changing the
state of the bundle bit (about which much more below) is usually a
Real Bad Idea - no consequences, but Norton Utilities (etc.) won't
love you. A diamond means the first file in the batch has its
bundle bit set.

Remove PS font BNDLs: clears the bundle bit _and_ removes any
ICN#-family resources, the BNDL resource, the FREF resource, and
the font's owner resource (e.g., 'APSF' for Adobe PostScript
Fonts). In other words, what's left when this is done will be
'POST' and 'vers' resources, if any. Works _only_ on files with
type 'LWFN' (PostScript Type 1 or Type 3 fonts from any foundry).
The effect is to make copying fonts as fast as copying any other
like-sized documents. Further down, we'll discuss why this is so. A
circle means that one or more files in the _batch_ are LWFNs with
bundle bits set. As with "Remove custom icons", this is harmless on
files that _don't_ have the resource types we're omitting. Fonts
processed this way will have their creator changed to sTp2 and will
have a special Shane the Plane font icon applied to them.

(Fair warning: This is a one-way street. Short of reverting to a
back-up of your fonts or going back to their original floppies, you
can't put this djinn back in the bottle. I can't imagine why you'd
want to, but it's only fair to mention that you are making a
_permanent_ change to the files.)


Parting shot: there is a lot of intelligent disabling going on with
these Finder flags. The intent behind this (freely confessed)
modality is to avoid doing potentially logically conflicting things
(quasi-)simultaneously. In truth, I could allow you to, for
example, make the batch of files invisible while making all others
in the folder visible. But it seems to me to invite confusion. In
other cases, such as "Remove PS font BNDLs", the disabled functions
would contend with great vigor, something like an alligator fight
leaving two well-fed dead 'gators (grin). In any case, the
admonition is: "But, gentlemen, you _overdo_ the mode" (emphasis
added). In software that is this dangerous (as I will keep pointing
out), it doesn't seem overdone to me...



5. Not for Flight Engineers only...

Okay, this is details regarding the details:

For starters, here's something cool: Because Shane the Plane is
Apple Event-aware, you can Drag & Drop batches of files from
multiple folders, then execute the whole widely dispersed batch
when you hit Start. In general, I expect this is mere frill, but I
opted not to make it _im_possible (it's possible by default)
because I thought it might be useful occasionally. Every time files
are Dropped on the icon the entire batch and all relevant folders
are queried for the batchwise information reported in Finder flags,
so that information is always up to date for the _whole_ batch
(Remove custom icons and Remove PS font BNDLs) and for _every_
folder from which files have been Dropped (Make all in folder
visible). This is important: if you check Make all in folder
visible, every file in _every_ affected folder will be made
visible. Take note also that Shane the Plane imposes a 256 file
limit on the size of a batch. This would not be a problem with
files Dropped from one folder, since 256 files in a single folder
is slow death, but it might come up with files Dropped from
multiple folders. Normally my Drag & Drop stuff imposes no limits
(though I often say "512", just to establish that the number is so
large as to be meaningless). But in Shane the Plane we are storing
information about each file Dropped, and I wanted to keep the
memory commitment relatively small.

Near the point: the default memory partition of Shane the Plane is
and _must be_ 512K. If you watch About this Macintosh/the Finder,
you'll see that the bar never gets filled. You might think this
means there is some room for you to cut the partition. There isn't.
While we're running, we're allocating and disposing of large blocks
of memory faster than the Finder can record, so the heap often _is_
completely filled, even though the Finder doesn't report that fact.
This is not really a terribly large problem, since we're checking
to make sure we have the memory we need before we commence to doing
anything. If we're short on memory, we don't do any work.

(For what it's worth: you should never change the memory partition
on utility software. You can safely change it on (Window-oriented)
applications software, because each opened Window has associated
dynamically allocated memory. If you can live with fewer windows,
you can live on less memory. But: in general, (Dialog-oriented)
utility software uses statically allocated memory and will
malfunction if it can't get all it needs. Certainly it will thrash
a lot more, compacting and re-compacting the heap to make space for
itself (this is also true of Window-oriented software), and it may
act very flakey. Making the partition smaller is an anachronism
from the days when Macs were small and stupid. I think it's best
forgotten, with the rule of the road being, if you want to change a
partition, make it _larger_...)

As mentioned above, Shane the Plane's Apple Events-awareness makes
it (conceivably) possible to run it from an intelligent agent. I
don't know enough about scripting to tell you how to do this, but I
_do_ want to point out that, at a minimum, your script will need to
be able to issue a "return" (0x0D) or "enter" (0x03) keystroke.
This is because Shane the Plane _must_ be explicitly started by
hitting the Start button. Since that button is the default, you can
"hit" it with the keystrokes, but you _must_ post some kind of
event to initiate execution. I don't know if this is possible with
Frontier or AppleScript alone, but certainly it is possible using a
QuicKey in combination with scripting software. To do this
properly, you should spawn a copy of Shane the Plane with all the
prefs you will want set and Saved; the Auto-pilot|Prompt radio
group should be set to "Auto-pilot". I don't know that I love this
as an idea, but it will work; it will take software that more or
less requires interaction and make it run as an unattended daemon's
familiar.

Eminently nerd-like hack: every piece of software by me that has a
Preferences menu (Shane the Plane, Clip 'n' Save, ShawBerry, and
the forthcoming Mark My Words) stores its preferences in the
resource fork of the software itself. The Default prefs are stored
in 'PREF' resource 128, and the Saved prefs are stored in PREF 129.
When you Save preferences, PREF 129 is re-written with your new
settings. If you are comfortable with ResEdit, you can use it to
give yourself two sets of stored preferences. Do this (on a _copy_
of Shane the Plane, of course):

1. Establish you second-favorite settings and Save preferences.
Quit.

2. Open the copy of Shane the Plane from ResEdit, and navigate your
way to PREF 129. Select all and Copy.

3. Open PREF 128, Select All and Paste. Save and Close the file. The
two resources are now identical, with both containing your
second-favorite settings.

4. Launch Shane the Plane again and establish your (first-)favorite
settings and Save preferences. Now when you do Restore defaults,
you'll get your second-favorite settings, and when you do Restore
saved prefs, you'll get your (first-)favorite settings, which will
also be loaded automatically with every subsequent launch.

If you have DiskTop or DeskZap or some other utility that lets you
change Finder flags, you may wonder why Shane the Plane gives you
access to so _few_ of them. The reason is this: because most of
them are utterly useless. DiskTop and DeskZap give you access to
_all_ of them, even though most of them are without practical
consequences. There is one exception, which we're going to discuss.
The Inited bit says that a file has been seen (initialized) by the
Finder; it has been recorded in the Desktop database, and its
position in the folder has been established. What this means is
that you will _never_ see a healthy file that _has not_ been
Inited. If you clear this switch in DiskTop/DeskZap, the Finder
will reinitialize the file in short order, with the (possible)
observable outcome being that the file will move in its folder.
Originally, Shane the Plane was going to make the Inited bit
available to be changed, but we left it out because it's so
preternaturally useless. _However,_ there _are_ a few occasions
where we're changing it on our own: the Inited bit is cleared in
instances where the Finder is reluctant to update in a timely
fashion (as with Lock name and Stationery pad). And: the Inited bit
is cleared when the result of a switch setting is to create a new
file from the old (Install custom icons, Remove custom icons,
Remove PS font BNDLs, and Insert slug line in text files).

Take note with respect to the above paragraph: except for changing
the Inited bit in the few instances named, we are being careful
to change only the things you ask to have changed. So, for example,
even though the effect of Remove custom icons is to create a new
file identical to the old but with the icons omitted, the
created/modified dates and times will _only_ change if you
explicitly change them. Likewise, all of the goofy Finder flags to
which you do not have access from Shane the Plane are passed
unaltered.

I wanted to say a few words about Make invisible. For the most
part, I think it's a Real Bad Idea. Apple explicitly advises
against it, with what seems to me to be good reason. On the other
hand, I myself have particular need to make a certain few files
invisible. So what I have to say is this: if you don't have an
overwhelmingly good reason to make files invisible, don't do it.
They do not call attention to their presence, so they can soak up
valuable hard disk real estate without your knowing about it. It is
_because_ they are potentially so pernicious that Shane the Plane
looks for them wherever he goes, offering you the chance to make
them visible.

Regarding Remove PS font BNDLs: Did you ever double-click on one of
your font folders, then have to reboot because the damn thing
wouldn't open? Did you ever wonder why it takes so long to copy a
font folder? Well, here's a real knee-slapper: it's because the
font vendors are deliberately crippling your Macintosh with
advertising!

To quote Dave Barry: I am not making this up!

If you drop an unaltered PostScript printer font file on Shane the
Plane, you'll see that it "Has BNDL resources". What does this
mean...?

The BNDL resource (itself) associates a file's owner resource (same
name as the Creator type), it's FREF resource, and its icons. The
presence of the BNDL resources (with the bit set) occasions an
entry into the Desktop database for the file (almost always
executable software). The Desktop DB entry tells the Finder what
icons to use for files (associated FREF entries) created by the
software. Because of this, ordinary files don't need BNDL resource
of their own.

The most notable exception to this logic is PostScript printer font
files, each of which has a set BNDL resources. Why? For reasons of
vanity and advertising. Since there is no application associated
with fonts, they'd come up with plain document icons without their
BNDLs. It's the BNDLs, not the +/- 400 bytes of excess resource
baggage, that make fonts so slow to copy, etc.; each one must be
entered in the Desktop DB for no good reason.

To make this clear: _because_ PostScript printer font files have
BNDL resources, the Finder must spend a _lot_ more time dealing
with each one than it would have to do if the BNDL resources were
stripped and the "Has BNDL resources" bit cleared. This is what
Shane the Plane does if you select "Remove BNDL resources". It is
not enough to simply clear the bit, since disk-fixing utilities
like The Norton Utilities will simple reset it at their next
opportunity. But after the resources are removed and the bit
cleared, the printer font files will behave as normal documents.
They'll copy as fast as any other like-sized documents and their
folders will open as quickly as other folders with that many files
in them (still not awfully fast to be frank, but fast_er_). They'll
still be perfectly fine _as fonts_, since, qua fonts, all that
matters are the POST resources (Type 1) or the contents of the data
fork (Type 3), all of which is retained. All we're doing is ripping
out the Mac-crippling advertising.

(Take note: this function will change _only_ files of type 'LWFN',
but it will change LWFNs with any creator (that is, from any
vendor).)

BNDL issue 1: making this change may violate your license agreement
with your font vendor(s). If it does, you're on your own, but I'd
_love_ to hear the font vendors assert their legal right to cripple
and crowd your computer with entirely non-functional,
hyper-redundant advertising. Unlike the FreeWare utility DeBNDLer
(which does not work for me), we are not preserving the owner
resource as a 'vers' resource, which means the copyright
information will not be visible from the Get Info window _unless_
the font has 'vers' resources of its own (as do, for example, all
Agfa fonts). The font is still protected by copyright however! (I
would say "obviously", but there is evidence enough that people
find this little bit of obviousness too easy to overlook.)
Moreover, it is still _explicitly_ copyrighted in the POST
resources and/or data fork. It will have a Shane the Plane creator
and a distinctive Shane the Plane printer font icon, but it is
still and always the copyrighted intellectual property of its
original vendor, usable and transferrable only according to the
terms of the license agreement. In other words, I can't believe a
judge would fault you for stripping out the BNDLs, especially given
their hostile perniciousness. But I have no doubt at all that a
judge would (quite properly) nail you to the wall for using Shane
the Plane as your excuse to steal fonts.

BNDL issue 2: because font folders take so long to open when the
fonts still have their BNDLs (the folders _do_ open, it just takes
longer than normal mortals can stand to wait), I have made a
folder-aware Drag & Drop utility called Oscar the (Moderately
Awe-Inspiring) Cat (who is pictured in About Shane the Person).
Oscar the Cat removes the BNDLs and clears the BNDL bit from any
LWFNs found in that whole folder _hierarchy_. In other words, it
starts immediately within the folder Dropped and works its way down
that whole folder tree. Oscar the Cat ships only with the
unrestricted version of Shane the Plane, and is licensed only to
purchasers of the unrestricted version of Shane the Plane. You
would use it like this: do all your existing fonts at once with
Oscar the Cat, then process newly purchased fonts with Shane the
Plane.

Here's an interesting question: what is the point of "Change file
names/Use text file's slug line"? This is Kip Shaw's agenda, his
methods are covered in detail in Appendix A. His text is eminently
worth reading, since he is developing a hyper-efficient
text-processing methodology around Shane the Plane and other tools.
But here's the short course:

1. Suppose you are going to be using a bunch of utilities like
mine, each of which will add its own extension to the files it
produces. Before doing anything, you could run the originals
through Shane the Plane, checking "Insert slug line in text files".
This will put the file's own true original name within it. Then you
run all the extension-appending utilities. When you finish, take
the final versions of the files and Drop them on Shane the Plane.
Check "Change file names/Use text file's slug line". The files will
be renamed with the true original names of the true original files.

2. This is Kip's coolest trick the quick way: suppose you have a
great batch of similar files. My own utilities (such as Torquemada
the Inquisitor) will do the same stuff to each file of a batch, but
if you have to make global changes in an interactive editor, it
would be far better to have all the text in one file. Otherwise,
you'll have to make each global change in each file - slow and
error-prone. So what you could do is this:

a. Run the originals through Shane the Plane, checking "Insert slug
line in text files". This will put the file's own true original
name within it.

b. Concatenate the whole batch of files (using my own Cat o' Seven
Tails, for example).

c. Do all of your editing on the concatenated file, using either
your interactive editor or batch-oriented utilities.

d. Segment the concatenated file using my Caesura. Divide at "//
Filename:" (which is one reason why this text is so odd) and select
"Divide at paragraph-ending BEFORE string". This will chop the
files back up in their original segments. But: their names will be
auto-generated by Caesura. So:

e. Run the newly created segments through Shane the Plane, checking
"Change file names/Use text file's slug line". The files will be
renamed with the true original names of the true original files.

If your goal is to show these files as "galleys", you can elect to
retain the slug line on the second pass through Shane the Plane.
That way, other people editing paper copies of the text will know
which file they are working on. Otherwise, you can elect to omit
the slug line. As discussed above, the slug line is omitted
automatically when the Auto-pilot|Prompt radio group is set to
"Auto-pilot". When it is set to "Prompt", you will be prompted once
per session to discover what you want to do.

Shane the Plane and aliases: Shane the Plane resolves aliases to
the _true file referred to by the alias_. That is to say: if you
Drop an alias of a file on the icon, the alias itself will not be
altered, the file _referenced_ by the alias will be altered.
Forewarned is forearmed!

Finally, as your reward for wading through all this stuff: you can
abort a Drag & Drop batch of files after you hit the Start button
by holding down the Command and Period keys. The abort will happen
_between_ files, so anything already started will be fully done,
and anything unstarted will be undone. Rather than trying to figure
out what to do next, we're just beeping twice then quitting, to
give you the opportunity to do what you need to before proceeding.
Given that I'm mentioning it this late in the manual, you might
guess that I think this abort feature is a Real Bad Idea. I've only
implemented it so that you can contain the damage, if you realize
late that your settings are a horrible mistake. My main advice is:
this software is DANGEROUS, so don't make horrible mistakes! (grin)



6. About Greg Swann...

Okay, here's the deal: I'm not just a developer, I'm a user of
software as well. I make about half of my money doing Desktop
Publishing. In consequence, I have a pretty clear idea of how to
focus utilities designed to plug gaps in the functionality of major
applications. I am quite sure there are a _lot_ of developers
brighter than I am. But the evidence of experience suggests that
few of them have my advantage of living on both sides of the line,
so to speak.

What does this mean?

First, it means that I have written a _lot_ of mission-critical
utilities in support of the software categories of interest to me:
file management, font management, automated text processing,
PostScript-processing, and automated DTP-software preparation. All
but four of these utilities are FreeWare (the exceptions being
Shane the Plane and the three packages discussed below) and are
available on CompuServe (GO DTPForum, Library 5, BROwse on
70640,1574) and other electronic information services (including
any service offering access to the Arizona Macintosh User's Group
BBS-In-A-Box CD-ROM).

Second, it means that if you are likewise interested in these
software categories, it behooves you to support my work. Fanmail is
always nice, of course, but remuneration is the sincerest form of
flattery (grin). Seriously: this is a business, even if a
microscopically small one. It has been worthwhile so far because
the other things commanding my attention have not been as
lucrative. But that is changing (of course, and obviously,
_because_ of all the software). I can make a _lot_ of money writing
custom software for contracted clients. And I can streamline my own
production work without having to monkey-proof and document my
tools. So: if I am to keep doing this, I have to make it pay. If
you _want_ me to keep doing it, you have to pay me. It's that
simple.

In many ways, retail software is simpler. You pay or you don't
play, and no one has any illusions. The difference is, the
developer needs a _much_ larger capital commitment, and he needs to
surround himself with babbling morons in suits who might - just
possibly - be good for something other than chuckling about
football. Electronically distributed software gets around that
trap, but introduces the problem exposed here: the ambiguity of the
sales transaction results in a lot of prostrate begging by
developers. I don't beg, but I don't work for free except on my own
terms for my own good reasons.

There are three possible "futures" for authors of electronically
distributed software. 1. The rewards do not justify the effort, so
the author goes and plays tennis or something. 2. The author
produces software as an after-work hobby and continues to do so
more or less irrespective of user-response (some of the best and
worst FreeWare comes out of this category). 3. The author's growing
reputation results in him getting more contracted custom
programming work, worth more money, to the point that he no longer
has time to produce electronically distributed software.

It is the last that is happening to me, and this is why you need to
support my work, if you want it to continue. I'll do all right
whether I'm working on problems that confront you or on the
problems of some corporation. But: if you are using software by me
that has a commercial version (and all of them are discussed here),
and if you want me to _continue_ thinking about your problems,
rather than the problems of Consolidated MediCalc - you know what
to do...

These are my commercial programs (excluding Shane the Plane, about
which you might already have heard a word or two (grin)):

XP8 - a very intelligent file filter that cleans up and makes the
filthiest text QuarkXPress-ready. Among many other features, it
offers DOS-file reformatting, financial-text clean-up, garbage
disposal, typographic quality enhancement, and the best quote
conversion we know of. The ShareWare version of XP8 (v1.0.0) can be
found on CIS, GO DTPForum, Library 5, under the name XP8.SEA. It is
also included on the distribution disk for the unrestricted version
of Shane the Plane. The current commercial version is v1.0.6 and
offers a great many enhancements over the ShareWare version.

Torquemada The Inquisitor - batch global search and replace
software with wildcards, pattern matching, string substitution, et
very cetera. With Drag & Drop under System 7, you can run up to 640
searches on up to 128 files in one batch. Features the most
intelligent case-conversion we know of. The most-recent FreeWare
version (1.1.0) can be found on CIS, GO DTPForum, Library 5, under
the name TORQUE.SEA. It is also included on the distribution disk
for the unrestricted version of Shane the Plane. The current
commercial version is 1.2.2, offering a great many enhancements,
including new "wildthings" and a _lot_ of new User Interface power.

Mark My Words - (currently in development, shipping mid-March (or
bust!)) very intelligent, configurable conversion of Microsoft Word
4.0/5.0/5.1 and WriteNow 3.0 files to QuarkXPress tags. As much of
the original coding as you want is maintained, and yet you are able
to make very fast global edits (e.g., with Torquemada). Moreover,
you can continue to draft and edit text in your Word Processor
while retaining the power and robustness of XPress Tags. With Em
Software's Xtags, you can even retain in-line pictures, tables and
borders. A sort of "PreWare" vision of the Mark My Words schema can
be seen in a program called WordLess Plus, which can be found on
CIS, GO DTPForum, Library 5, under the name WLPLUS.CPT. A DemoWare
version of Mark My Words will be posted to CompuServe and other
on-line services when it becomes available. This demo will also be
included on the distribution disk for the unrestricted version of
Shane the Plane when it becomes available.

(While I've vectored all the files toward CIS, my primary haunt,
they are also available on other services, and on any BBS which has
the most recent version of AMUG's BBS-In-A-Box CD-ROM on line.)

All three of these programs are sold on the same terms: (US)$50
each, per license. Two to 10 licenses are $45 each, and 11 or more
are $40 each. All of these programs will eventually be rolled into
a stand-alone text editor cum word processor currently in design
with the working name "MyEditor". You will be entitled to a 25%
discount on the price of the MyEditor, when it is released, for
each of these utilities you have purchased and registered. In other
words, if you own XP8, your discount will be 25%. If you own XP8
and Torquemada, it will be 50%. And if you own all three, you will
be entitled to a 75% discount. (This discount does not apply to
Shane the Plane, which is establishing its own upgrade path.)

If you want to buy any or all of these programs, send a check or
money order* to:

    Greg Swann
    P.O. Box 1724
    Andover, MA 01810

*Outside the U.S., you may send cash at your own risk, if exchange
issues make that expedient.

These programs are included on the distribution disk for the
unrestricted version of Shane the Plane:

* Shane the Plane v2.0.1 - discussed here as some length (!)

* Oscar the Cat v1.0.0 - PostScript font BNDL removal software
licensed as a premium to purchasers of Shane the Plane.

* XP8 v1.0.0 - ShareWare version of the commercial software

* Torquemada the Inquisitor v1.1.0 - FreeWare version of the
commercial software

* Mark My Words v1.0.0 - DemoWare version of the commercial
software (when it becomes available)

* Caesura v1.0.0 - FreeWare file segmentation software

* Cat o' Seven Tails - FreeWare file concatenation software

Plus some other stuff...



7. Conclusion...

Jeez, haven't you had _enough_...? (grin)

Seriously: that's it. If you have any questions or problems, the
easiest way to get hold of me is on CompuServe at 70640,1574
(Internet [e-mail]). If you can't do that, you can
snail mail me at:

    Greg Swann
    P.O. Box 1724
    Andover, MA 01810



Very Best,



Greg Swann

7/8/93





Appendix: Real World Shane the Plane

... or ...

What good is a shortstop without the other infielders?



by Kip Shaw



Fleet of foot and with a mighty arm, Shane covers a lot of ground
deep in the hole. But once he's snagged a wicked line drive, who's
he going to throw it to? Thanks to Manager Greg Swann (whose team
is aptly called the "Swanney Ribbers" because they are fond of
jokes), some shrewd trades were made: Protecting second base is
"Cat o' Seven Tails," and over at first is that fearless lefty
"Caesura." Some may say, "But are they as good as Tinker, Evers,
and Chance from the glory days of the Chicago Cubs?" You bet they
are. Here's how they turn a triple play.

First, let's describe the wicked line drive that is streaking
toward Shane: it's a batch of text files generously provided by one
of your friendly clients. Unless you've housebroken this client,
the files no doubt will be filled with garbage. Not only will you
need to weed out all the multiple spacebands, multiple carriage
returns, etc., but you might also be called upon to do some
copyediting - perhaps relatively simple stuff like making all the
"a.m."s and "p.m."s consistent, or maybe a whole lot more. Before
you plunge into these tasks, let Shane snare this line drive - drag
& drop all the files on Shane and do this: check *on* the "Insert
slug lines in text files." As previously described in these docs,
this will put the filename at the beginning of each file.

The slug line looks like this (everything between but not including
the rows of dashes):

-----
// Filename: nameOfFile

-----

with "nameOfFile" being (surprise) the name of the file that appears
in a Finder window and the file's title bar. If you're not happy
with the names of the files - perhaps the client made them
unnecessarily long or uselessly nondescriptive - then also do this
in Shane at the same time: check *on* the "Change file names"
checkbox and select "Prompt individually" in the popup. In this
way, you can quickly change some or all of the file names and
*also* have the new names inserted as a slug line in the text
files.

Now that all the files are properly slugged, it's time for Shane to
whip the ball over to the secondbaseman, "Cat o' Seven Tails." For
those of you who might not be aware of Cat's prowess, let me wax
eloquent: Cat does one thing, and does it lightning fast - he
concatenates. For those of you who don't know what "concatenate"
means - look in the dictionary! <g> Okay, I'll tell you -
"Concatenate. To connect or link in a series or chain." So, if you
drag & drop all your now-Shaned client's files onto Cat, they will
be joined together (in the order they were selected in the Finder)
into one file, aptly named "Concatenated files." Why, you ask,
bother to join all the files together? Why not continue to work on
them individually? Sure, you could work on them separately, but
often - especially when editing is involved, and you need to refer
quickly back and forth between files - it can be a whole lot easier
if they're all in one file. And don't worry - once the ball gets
over to our first baseman, you will easily be able to split them
apart again.

But we're still at second base with Cat. Do whatever copyediting you
need to do on the "Concatenated files" file. Run it through XP8 and
Torquemada (who are other stellar members of the Swanney Ribbers).
Massage that text to your heart's content! Once done, you might have
a file now named "Concatenated files.XP8.TQM.XP8.TQM.SB!." ("SB!" -
what's that, you ask? Another member of the team - ShawBerry - a
true hall of famer. But that's another story.)

Okay. So Cat and his teammates have now served up something like
"Concatenated files.XP8.TQM.XP8.TQM.SB!." Time to sling that
over-extended filename to the fearless firstbaseman, Caesura. Some
fans of a rival team have spread malicious rumors that Caesura is
Cat's evil twin - but don't pay any attention to this gossip. The
slander started when it was discovered that Caesura has only one
goal in life - to undo what Cat has done. Caesura *splits* a file
into segments. What these rival fans didn't realize, though, is
that Cat and Caesura work in harmony. Here's how:

First, do yourself a favor: shorten the bloated filename to
something like "Catted" because Caesura likes to add its own
extension to the file name, which will makes things even more
unwieldy. Then boot up Caesura and you'll be asked two things: 1)
"Specify a string at which to divide" and 2) whether to "Divide at
paragraph-ending BEFORE string" (the default) *or* "Divide at
paragraph-ending AFTER string." Thanks to shortstop Shane, our
string of choice is easy: "// Filename" - and, therefore, we should
use the "Divide before string" default. Then, click on Caesura's
"Start" button and navigate in the dialog over to our baseball -
"Catted" - then click on the "Open" button. Caesura will now split
the catted file into the original segments that your client gave
you. Only problem is that the filenames will be useless - Caesura
simply appends a numerical extension to each of the segments -
e.g., "Catted.001" - not very descriptive!

But like any peerless infielders who have just completed a triple
play, the ball is flung around the horn - back to Shane. Drag &
drop the Caesura-segmented files onto Shane, and in the "Change
file names" popup, select "Use text file's slug line." (You might
also want to change the creator/type to your favorite text editor
at this point to rid yourself of the Caesura creator/type.) Just
like magic (which any fan will tell you baseball truly *is*), Shane
restores the original file names. You'll notice that the first
Caesura-segment's file name hasn't changed - it's still
"Catted.001." That's because it's garbage - a non-file - because
there obviously wasn't any text found before the first "//
Filename" string that was the marker you entered in Caesura. You
can trash it.

That's it. Inning over. And like all triple plays, it takes less
time to *do* than to *describe.*